Method and system for asset management

ABSTRACT

An asset management system can include one or more beacons, a remote computing system, and a program. The asset tracking method can include operating the beacon according to programmable instructions, and can additionally or alternatively learn to detect events.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Nonprovisional applicationSer. No. 17/082,513 filed 28 Oct. 2020, which is a continuation of U.S.Nonprovisional application Ser. No. 16/551,379 filed 26 Aug. 2019 whichclaims the benefit of U.S. Provisional Application number 62/722,397filed 24 Aug. 2018, US Provisional Application number 62/772,534 filed28 Nov. 2018, and US Provisional Application number 62/881,766 filed 1Aug. 2019, each of which is incorporated in its entirety by thisreference.

This application is related to U.S. application Ser. No. 15/620,014filed 12 Jun. 2017, U.S. application Ser. No. 16/271,080 filed 8 Feb.2019, U.S. application Ser. No. 15/789,767 filed 20 Oct. 2017, U.S.application Ser. No. 15/836,291 filed 8 Dec. 2017, and U.S. applicationSer. No. 15/784,774 filed 16 Oct. 2017, each of which is incorporated inits entirety by this reference.

TECHNICAL FIELD

This invention relates generally to the field of wireless communication,and more specifically to a new and useful method for managing an assetin the field of wireless communication.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of the method.

FIG. 2 is a schematic representation of the method.

FIG. 3 is a schematic representation of the system.

FIG. 4 depicts variants of information shared between components ofsystem.

FIG. 5 is an example of information shared between components of systemassociated with S200.

FIG. 6 depicts variants of information shared between components ofsystem.

FIG. 7 depicts an example set of components of an anchor beacon.

FIG. 8 depicts an example of the radio layout of an anchor beacon.

FIG. 9 depicts an example set of components of the secondary beacon 300.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. Overview.

As shown in FIG. 1, the method includes: operating an anchor beaconaccording to instructions determined by a client S100, and additionallyor alternatively includes operating the anchor beacon according to alearned model S200. The method functions to enable users to specifycustom beacon responses (e.g., through user-provided programs), whilemaintaining centralized beacon population control (e.g., by the remotecomputing system, beacon registry, etc.)

As shown in FIG. 3, the system 30 preferably includes: a client 360, aprogram 380, a remote computing system 400, one or more anchor beacons320, and can additionally or alternatively include one or more secondarybeacons 300. The system additionally or alternatively includes any othersuitable element.

The method is preferably performed using the system 30, however, themethod can additionally or alternatively be performed using any othersuitable system.

2. Benefits.

The inventors have discovered that a mobile device can be deployed toaid in asset management.

First, the inventors have discovered that conventional methods toprogram mobile devices, such as IoT devices, can be challenging. Theinventors have developed a system that enables a user (e.g., via aclient) to program a beacon (e.g., mobile device) by compiling code(e.g., user-provided code, template functions, etc.) into bytecode,wherein the bytecode can be sent to (e.g., flashed onto; transmitted to,such as via Web Bluetooth™; etc.) the beacon (e.g., after beaconmanufacture, after beacon sale). In variants, the client can be a webbrowser, wherein the code can be written in a web-based programminglanguage (e.g., javascript) using a set of beacon parameter abstractions(e.g., beacon abstractions, location abstractions, etc.), and compiledat the remote computing system into bytecode, wherein the bytecode canbe sent to the beacon (e.g., via the client, directly to the beacon viaa cellular connection). These variants can be particularly compellingbecause it allows users to program in a familiar language (e.g., aweb-based programming language), and also to use a set ofhuman-understandable abstractions. In these variants, the remotecomputing system can disambiguate or resolve the abstractions (used forfacile programming purposes) into the specific beacon identifierstrings, the specific list of beacon identifiers associated with a givengeographic identifier, the geofence or geocoordinates associated withthe geographic identifier, and/or any other suitable information,wherein the disambiguated information can be compiled into the bytecodeand sent to the beacon for execution. Furthermore, this frees beaconmemory by reducing the parameters and/or associations stored at eachbeacon.

Second, in variants, the beacon can be trained to identify events. Forexample, a beacon can log sensor data during a training session (e.g.,while the beacon is in a training mode and the beacon is subjected tothe event) and send the sensor data to a remote computing system (e.g.,in a batch, streamed, etc.), wherein the remote computing system cangenerate a model based on the sensor data, compile the model intobytecode, and send the model back to the beacon. In specific exampleswhere the model is being executed on a dedicated on-board processor(e.g., coupled to the IMU, separate and distinct from the mainprocessor, etc.), the model can be received at the main processor andsent to the on-board processor for storage and execution. However, thebeacon can be otherwise trained.

Third, the beacon can provide high-accuracy location measurements (e.g.,sub-io-cm measurements) in a low-power manner when stationary and/orduring translation. In one example, the beacon can determine an initialbeacon location using one or more UWB radios (e.g., using time of flightof the UWB signal), determine the amount of beacon translation using anon-board IMU, and determine the beacon location based on the initialbeacon location and the IMU readings (e.g., using odometry).

However, the beacon can confer any other suitable set of benefits.

3. System 30.

The system 30 preferably includes: a client 360, a program 380, a remotecomputing system 400, one or more anchor beacons 320, and canadditionally or alternatively include one or more secondary beacons 300.

The system 30 can include one or more secondary beacons 300. Thesecondary beacon preferably aids in determining the anchor beacon'slocation (e.g., indoor position; presence within a predeterminedgeographic region, such as a building; etc.), but can additionally oralternatively provide any other suitable set of functionalities.

The secondary beacon (e.g., venue beacon) is preferably positioned in avenue (e.g., in a manufacturing facility, office building, store,center, vehicle etc.), but can additionally or alternatively bepositioned on a venue (e.g., on a vehicle, tent, gate, doorway etc.), onan asset (e.g., person, cart, package, item, etc.), or otherwisepositioned. The secondary beacon is preferably statically mounted to themounting point, but can be transiently mounted to the mounting point.The secondary beacon is preferably associated with the mounting point(e.g., in the beacon registry, maintained by the remote computingsystem), more preferably representative of the mounting point's location(e.g., geolocation, indoor position, etc.), but can be additionally oralternatively associated with any other suitable information.

In variants, the secondary beacon can have limited processing powerand/or functionality. In one example, the secondary beacon operatesaccording to manufacturer-provided, standard bytecode, wherein the usercan set variable values (e.g., determining scanning and advertisingfrequency), but the user cannot specify event detection andtransmission. However, the secondary beacon can be otherwise configured.

The secondary beacon is preferably operable during an active session.The active session can be determined by the client, remote computingsystem, by the secondary beacon (e.g., in response to packet detection,motion detection, presence detection, etc.), and/or otherwisedetermined. However, the secondary beacon can be otherwise operable.

The secondary beacon is preferably operable between one or more modes.The secondary beacon can operate in each mode at a frequency andaccording to operation conditions specified by the standard bytecode(e.g., periodically at a predetermined advertising period), but canoperate according to predetermined settings, according to settingsreceived from the remote computing system (e.g., wherein the remotecomputing system can control a limited set of beacon functions, such asadvertising schedules, wake schedules, scanning schedules, etc,), oraccording to any other suitable set of instructions.

The modes can include: an advertising mode, a scanning mode, an offlinemode, and/or any other suitable set of modes.

The advertising mode preferably includes using one or more Bluetoothradios to advertise a secondary beacon identifier, but can be otherwiseexecuted. The secondary beacon can optionally transmit a payload (e.g.,wherein both the secondary beacon identifier and the payload can beincluded in a frame broadcast by the secondary beacon), and/or any othersuitable information in the advertising mode.

The secondary beacon is preferably operable in a scanning mode. Thescanning mode preferably includes using one or more Bluetooth radios toscan for secondary beacon packets, the packets comprising one or morebeacon identifiers. The Bluetooth radio can optionally collect signalprocessing information (e.g., RSSI, TOF, etc.), and/or any othersuitable information associated with the received packets.

The secondary beacon is preferably operable in an offline mode. Thesecondary beacon can operate in the offline mode when the secondarybeacon is not in an active session, and/or at any other suitable time.After determining an instruction to operate in the offline mode, thesecondary beacon can instruct all sensors and/or radios to operate inthe offline mode, and/or a subset of the sensors and/or radio to operatein the offline mode. However, the secondary beacon can additionally oralternatively be operable in any other suitable mode.

As shown in FIG. 9, the secondary beacon 300 can include one or morecommunication systems 306 (e.g., Bluetooth radios executing one or moreBluetooth protocol and/or specifications, such as Bluetooth Low Energy(BLE), Bluetooth Classic, Ultra Wide Band, Bluetooth 1,0, 1.1. 1.2, 2.0,2.1, 3.0, 4.0, 4.1, 4.2, 5.1, etc.), one or more processing systems 308,one or more power supplies 310, one or more secondary adhesive layers312, a secondary housing 302 enclosing and mounting the aforementionedcomponents, and/or any other suitable component. In a specific example,the secondary beacon consists essentially of one or more: short-rangecommunication systems (e.g., one or more Bluetooth radios, NFC radios,etc.), processing systems, power supplies, inertial sensors (e.g.,accelerometers), optionally ambient environment sensors (e.g., lightsensors, microphones), and a housing (e.g., with adhesive). However, thesecondary beacon can be otherwise configured.

The secondary beacon is preferably associated with a secondary beaconidentifier 605. The secondary beacon identifier can be static (e.g., bea static public identifier that can be used by user devices, clients,and/or third-party applications to trigger predetermined actionsassociated with the secondary beacon's public identifier), be transientor ephemeral (e.g., require a resolver to resolve the transientidentifier into the public identifier), and/or otherwise vary. Thesecondary beacon identifier is preferably advertised within a packet 615advertised by the secondary beacon, but can be otherwise used.

The association between the beacon identifier, the specific beacon, andany auxiliary beacon information (e.g., beacon location or mountingpoint information, transient identifier, etc.) is preferably stored by abeacon registry (e.g., managed by the remote computing system), but canbe otherwise stored. In one variation, the remote computing systemreturns information (e.g., location associated with the beacon, mountingpoint identifier, etc.) associated with a secondary beacon identifierreceived from the remote computing system from an intermediary (e.g.,user device, anchor beacon, etc.). In a second variation, the anchorbeacon performs a predetermined set of actions (e.g., user-specifiedactions, standard actions, etc.) specified by the anchor beacon bytecodein response to receipt of a packet with the secondary beacon identifier.In variants wherein the secondary beacon identifier is secured, theanchor beacon can optionally resolve the secured secondary beaconidentifier into the static public identifier (e.g., based on adeterministic calculation, based on a lookup table retrieved from thebeacon registry, etc.).

In another variation, the secondary beacon identifier can be encryptedusing a secondary beacon key to obtain a secondary beacon token. Thesecondary beacon key can be stored at both the remote computing systemand at the secondary beacon. The secondary beacon identifier can beencrypted at a predetermined interval. The predetermined interval can bebased on a clock wherein the clock is shared by the secondary beacon andthe remote computing system. For example, a secondary beacon identifiercan by encrypted with the secondary beacon key to obtain the secondarybeacon token and the secondary beacon token can be advertised by thesecondary beacon. After a predetermined period (e.g., every 20 minutes,every hour, etc.), a new secondary beacon identifier can be generated bya random number generator, the new secondary beacon identifier can beencrypted using the beacon key to obtain a new secondary beacon token,and the new secondary beacon token can be advertised by the secondarybeacon. However, the new secondary beacon identifier need not beencrypted, or can be otherwise encrypted.

However, the secondary beacon can additionally or alternatively beotherwise configured.

The system 30 preferably includes one or more anchor beacons 320. Invariants, the event models, programs (e.g., bytecode), and/or any othersuitable data or instruction set determined for a given anchor beaconcan be replicated (e.g., pushed to) other anchor beacons 320 in a givenpopulation, associated with a specific user account, and/or any othersuitable set of anchor beacons.

The anchor beacon preferably includes the components of the secondarybeacon, but can additionally or alternatively include any othercomponents.

The anchor beacon preferably includes one or more radios. The radios caninclude one or more Bluetooth radios (e.g., Bluetooth classic, BLE,etc.), such as those discussed above for the secondary beacon. Theradios can include one or more cellular radios (e.g., LTE), short rangeradios (e.g., NFC, RF), global navigation system radios (e.g., GPS,GLONASS, Galileo, etc.), and/or any other suitable set of radios. Theradios can include or share one or more chipsets. However, the radioscan additionally or alternatively include any other suitable radio.

In variants, the antennas of one or more radios can be arranged on thesame plane (and/or be mounted to a common board). The antennas for therespective radios can be: aligned (e.g., arranged in parallel), overlap,be radially distributed (e.g., arcuately distributed about a centralpoint, example shown in FIG. 8), or otherwise arranged.

The anchor beacon preferably includes one or more sensors. The sensorspreferably include one or more motion sensors (e.g., IMU, accelerometer,gyroscope), temperature sensors, light sensors, accelerometers, and/orany other suitable sensor. The sensors can share a chipset with theprocessing system and/or the radios, but can additionally oralternatively have individual chipsets (e.g., separate and distinct fromthe radio chipset, from the processor, etc.).

In a specific example, the IMU can have a separate, low-power chipsetthat is operated independently of the main processing system. Thelow-power chipset can execute one or more models (e.g., event models,learned models, etc.) and/or programs that are specific to the IMU.

The anchor beacon can include one or more processing systems. Theprocessing system can include one or more CPUs, GPUs, co-processors,microprocessors, clocks, storage, and/or any other suitable element. Theanchor beacon can include a power source (battery, RF, etc.), aconnector (e.g., data and/or port such as USB-c), memory, inputs (e.g.,buttons, microphones, etc.), outputs (e.g., lighting, audio), housingenclosing the components of the anchor beacon, and/or any other suitablecomponents. However the anchor beacon can additionally or alternativelyinclude any other suitable components.

In one variation, the anchor beacon includes two or more processors. Thefirst processor (e.g., the main processor) preferably processesbytecode, coordinate sensor operation, coordinates radio operation,and/or performs any other suitable function. The second processorpreferably processes machine learning features (e.g., running eventmodel, logging training data, etc.), but can additionally oralternatively process any other suitable feature. The anchor beacon canadditionally or alternatively include a third processor (e.g., securemodule). The third processor can store security keys, generate securitykeys, handle payload and/or beacon identifier encryption, and/or performany other suitable set of functionalities. The anchor beacon can includea housing, computer readable media, battery, a connector and/or anyother suitable component.

In one example, as shown in FIG. 7, the anchor beacon consistsessentially of: one or more processors 324; one or more co-processors326, wherein the co-processor(s) can include an AES encryption system,one or more random number generators (e.g., true random number generatorfor full entropy, or for any other suitable benefit), and/or anasymmetric/symmetric hashing cryptographic system; computer readablemedia 328 (e.g., RAM, Flash); one or more Bluetooth radios 330 (e.g.,BLE, Bluetooth classic, UWB radio 342, etc.); a global navigation system334 (e.g., that receives signals from one or more satellites 420); acellular radio 332 (e.g., modem); a battery 336 (e.g., lithium-ionrechargeable battery); connector 338 (e.g., USB standard, such as USB-C,USB-A, micro-USB, etc.; for data transfer and/or power transfer), a NFCradio (e.g., NFC programmable tag 344); a 3-axis accelerometer 340 orIMU; an optional programmable push button 348; programmable outputs,such as RGB LEDs; temperature sensor; adhesive layer 346; and housing322 (e.g., durable non-toxic silicon; encloses most or all of theaforementioned components). However, the anchor beacon can be otherwiseconfigured.

The anchor beacon preferably functions to track an asset. The anchorbeacon can execute one or more programs stored on-board the anchorbeacon. The anchor beacon can transmit event data to a remote computingsystem.

The anchor beacon preferably operates according to the instructions frombytecode 410. The bytecode is preferably based on code determined by theclient, but can be otherwise determined. The code is preferablyprocessed into (e.g., compiled into) bytecode by the remote computingsystem, but can additionally or alternatively be processed by theclient, by a programming device, or otherwise processed. The anchorbeacon is preferably user programmable, wherein the user can specify apredetermined set of functions and/or processes and the system (e.g.,the remote computing system) can convert the user-specified programsinto machine-executable code that is executable by the limitedprocessing capabilities of the anchor beacon, but the anchor beacon canbe otherwise programmed.

Similar to the secondary beacon, the anchor beacon can be operablebetween one or more modes. The anchor beacon can operate in each mode ata frequency and according to operation conditions specified by thebytecode (e.g., advertising schedules or periods, scanning schedules orperiods, transmit schedules or periods, wake schedules, sleep schedules,etc,), but can operate according to predetermined instructions,according to instructions or trigger events received from the remotecomputing system (e.g., wherein the remote computing system or bytecodecan control the set of beacon functions), or according to any othersuitable set of instructions. Examples of anchor beacon operation modesinclude: a training mode (e.g., wherein the anchor beacon collectstraining data while being subjected to an event), a processing mode(e.g., operating according to the bytecode and/or an event model 515,which can be received from the remote computing system or othercompiler), a scanning mode, an advertising mode, a transmitting mode, anoffline mode, and/or any other suitable

The anchor beacon can also function to sample data from on-boardsensors, receive secondary beacon packets (e.g., in the scanning mode),resolve individual beacon identifiers from the secondary beaconpacket(s), determine the secondary beacon's location relative to theanchor beacon (e.g., based on the RSSI, AOA, time of flight, etc.),determine the ego location (e.g., location of the anchor beacon) basedon known locations of each of a set of secondary beacons (e.g., that thepackets are received from) and the respective estimated separationdistance (e.g., determined based on the RSSI), communicate with theremote computing system via a cellular radio, communicate with theclient (e.g., via web Bluetooth, through the remote computing system,etc.), but can additionally or alternatively provide any other suitableset of functionalities.

The anchor beacon is preferably operable in a training mode 505, whichfunctions to generate an event model based on training data. The anchorbeacon operates in the training mode in response to a training modecommand (e.g., received from the user, received from a remote computingsystem, detected at the anchor beacon, etc.). The training modepreferably includes logging event data related to a predetermined event(e.g., user-specified event) wherein the anchor beacon is subjected tothe event (e.g., the user or other manipulator actuates the anchorbeacon). The log data can be streamed or periodically transmitted to theremote computing system (e.g., via the client, via an intermediarydevice, directly using the cellular radio, etc.). An example is shown inFIG. 5. Each successive instance of the event can be identified by theanchor beacon (e.g., wherein the anchor beacon labels each instance inresponse to receipt of a training mode command or other trigger),identified by the user (e.g., before or after each instance; after thedata is uploaded to the remote computing system, etc.), and/or otherwiseidentified.

The event model is preferably determined by the remote computing system(example shown in FIG. 5), but can be determined by the client, anintermediary device, or any other suitable computing device. The eventmodel is preferably determined based on the training data from thetraining session, but can be determined based on historic data,population data, and/or any other suitable data. The event model ispreferably determined based on a template model (e.g., for a specificprocessor, for the IMU processor, for the event, etc.), but can bedetermined based on a reference model (e.g., for the event, a priormodel, etc.), or otherwise determined. The event model is preferablysent to the anchor beacon (e.g., directly via the cellular connection,via the client, via an intermediary device, etc.), but can be executedby the remote computing system (e.g., wherein anchor beacon data isstreamed to the remote computing system) or otherwise stored andexecuted. In variants, the event model can be addressed to a specificprocessor for storage and/or execution (e.g., the IMU processor).

The anchor beacon is preferably operable in a processing mode 530. Theprocessing mode functions to detect one or more events 520. The eventsare preferably detected based on measurements sampled by sensorson-board the anchor beacon, but can be detected based on any othersuitable data. The events are preferably detected based on the bytecode,but can additionally or alternatively be detected based on an eventmodel, or otherwise detected. The anchor beacon can operate in theprocessing mode continuously, when in a wake state, in response tooccurrence of a precursor event, or at any other suitable time.

The anchor beacon is preferably operable in a scanning mode. Thescanning mode preferably includes using one or more Bluetooth radios toscan for secondary beacon packets, wherein the packets include one ormore beacon identifiers. The Bluetooth radio can collect signalprocessing information (e.g., RSSI, TOF, etc.), and/or any othersuitable information. However, the scanning mode can be otherwiseexecuted.

The anchor beacon is preferably operable in an advertising mode. Theadvertising mode preferably includes using one or more Bluetooth radiosto advertise anchor beacon identifier and additionally or alternativelya payload 420, and/or any other suitable information. However, theadvertising mode can be otherwise executed.

The anchor beacon is preferably operable in a transmitting mode. Thetransmitting mode preferably includes using one or more cellular radios(or other long-range radios) to transmit the payload 420 to the remotecomputing system (example shown in FIG. 4), but can additionally oralternatively transmit any other suitable information to any othersuitable entity.

The anchor beacon is preferably operable in an offline mode.

In one variation, the anchor beacon operates in the offline mode basedon an IMU event. An IMU event can be if the acceleration is below apredetermined threshold, such as zero (e.g., anchor beacon is notmoving) for a predetermined period of time. After determining that theacceleration is below the predetermined threshold, the anchor beacon caninstruct all sensors and/or radios to operate in the offline mode,and/or a subset of the sensors and/or radio to operate in the offlinemode.

In a second variation, if the acceleration is above a predeterminedthreshold (e.g., the same or different from the offline threshold), suchas not zero (e.g., the anchor beacon is moving), the anchor beacon caninstruct all sensors and/or radios to wake (and operate according to thebytecode). Alternatively or additionally, the anchor beacon can operatein the wake mode in response to the motion satisfying an event model.For example, the IMU can detect a predetermined motion pattern, and/orthe event model can detect event occurrence based on the anchor beacon'ssensor data, such as an airplane take off and landing. After detectingthe motion pattern or event occurrence, such as after the airplane is inthe air, the anchor beacon can switch all the sensors and/or radios tothe active mode, and/or operate according to (the remainder of) thebytecode.

However, the anchor beacon can be operable in any other suitable mode.

In a first example, the anchor beacon can advertise the anchor beaconidentifier. In a second example, the anchor beacon can scan for beaconpackets comprising associated beacon identifiers. In a third example,the anchor beacon can perform range finding by leveraging RSSI (e.g.,BLE, Bluetooth, etc.) and/or time of flight (UWB, classic, etc.). Inthis example, the anchor beacon can determine the ego location on-boardthe anchor beacon, transmit the requisite information (e.g., secondarybeacon identifier, RSSI, etc.) to the remote computing system, orotherwise determine the ego location.

In a fourth example, the anchor beacon can determine its outdoorposition using the GPS system and transmit coordinates to the remotecomputing system at a predetermined frequency. The coordinates can beused to track the anchor beacon (e.g., at the remote computing system),wherein the anchor beacon is associated with an asset.

In a fifth example, the anchor beacon can determine its outdoor positionusing the GPS system and refine the outdoor position using relativepositioning (e.g., to secondary beacons; with odometry, using the IMUmeasurements, etc.).

In a sixth example, the anchor beacon can determine indoor positionusing UWB radio (e.g, x, y, z coordinates; using time of flight (TOF),etc.). Over time, the anchor beacon can optionally use odometryassociated with IMU to refine the indoor position.

In a seventh example, the anchor beacon can encrypt a payload (sensordata, identifier, event model, and/or any other suitable data). Theanchor beacon can send the payload to the remote computing system, asecondary beacon, the client, or any other suitable entity. The anchorbeacon can encrypt the payload using a symmetric key protocol, anasymmetric key protocol, or any other suitable encryption scheme. Forexample, the remote computing system determines a public key andassociated private key and sends the public key to the anchor beacon.The anchor beacon receives the public key, generates a session key usingthe random number generator, encrypts session key using the public key,and transmits ciphertext of session key to the remote computing system.At the remote computing system, decrypt the ciphertext using the privatekey to obtain the session key. At anchor beacon, encrypt payload usingthe session key and remote computing system can receive and decrypt thepayload using the shared session key.

In an eighth example, the anchor beacon can enter a hibernation mode asthe battery level starts to decrease past an operable level. The LED canbe programmed to blink at a predetermined period (e.g., every 30seconds, 5 minutes, etc.). During hibernation mode, the clock cancontinue to operate. The sensors and/or radios can operate in theoffline mode.

However the anchor beacon can additionally or alternatively include anyother suitable component, and/or operate in any other suitable manner.

The one or more anchor beacons and the one or more secondary beacons caninteract. For example, the anchor beacon can be placed on an asset in afacility and secondary beacons can be placed at different locations inthe facility. The secondary beacons can advertise their beaconidentifiers and the anchor beacon can scan for the secondary beaconpackets. Using the packets, the anchor beacon can determine its positionbased on RSSI (or TOF) in the facility. When the anchor beacon is loadedinto a vehicle, the anchor beacon can receive satellite information fromthe GPS system and send the satellite information to the cloud (e.g.,remote computing system). Then at a second facility, wherein the secondfacility includes secondary beacons, the anchor beacon can detect itsindoor position based on the secondary beacons.

In another example, the anchor beacon can be attached in a vehicle(e.g., truck, van, car, airplane, pod, etc.), such as on the ceiling orside, and secondary beacons can be placed on assets wherein assets areloaded into the vehicle.

In another example, the anchor beacon can be attached to the inside of avehicle, and scooters or any other suitable asset can be placed invehicle. The asset can advertise identifiers to the anchor beacon andanchor beacon can transmit the asset identifiers to the remote computingsystem. The remote computing system can communicate with the user deviceto determine the number of assets and associated asset identifiers invehicle and/or any other suitable information (e.g., battery levels ofscooters, battery level of anchor beacon, etc.).

In another example, the anchor beacon attached to the outside of avehicle (e.g., bus, van, pod, etc.). A secondary beacon can be attachedto an asset (e.g., person, object, animal, etc.).

In another example, a secondary beacon can be placed at an entrance of aroom, and the anchor beacon can be connected to an entity (e.g., humansuch as a janitor).

However, the one or more beacons can otherwise interact.

The system preferably includes one or more clients 360. The clientpreferably functions as an interface for a user to generate and sendabstract code 405 to the anchor beacon (e.g., directly, indirectly via aremote processing system). The client can function as a user interfacefor the user to generate programs responsive to events generated by theanchor beacon. The client can receive program characteristics (e.g.,battery management estimation 415). The client can provide features suchas syntax highlighting, auto-completion, pre-written snippets (e.g.,functions, variables, etc.), and/or any other suitable feature. Theclient can additionally or alternatively provide any other suitable setof functionalities.

The client is preferably connected to the remote computing system. Theclient can be in the remote computing system, separate from the remotecomputing system, or otherwise positioned. The client can additionallyor alternatively be connected (e.g., wirelessly connected, wired) to thebeacons to be programmed (example shown in FIG. 3). The client ispreferably operable as an interface for a user to enter code. Theuser-entered code can be processed by the remote computing system intobytecode 410. In variants, the remote computing system can optionallydetermine a battery management estimation of the bytecode on a specificbeacon (e.g., the anchor beacon, secondary beacon, etc.). The powerestimation can be reported to the user via the client (e.g., while theuser is developing the code, after the user developed the code, or atany other suitable time). The bytecode can be read by the beacon(example shown in FIG. 4). However, the client can be otherwiseconfigured.

The client is preferably a browser application, but can additionally oralternatively be a native application, desktop application, or any othersuitable application. In variants where the client is a browserapplication, the browser can communicate with the beacons using webBluetooth or any other suitable protocol.

In an example, the client includes pre-designed template applications(e.g., GPS tracker, location to slack, alert button, Button and LED,Beacon Info, cellular location, cell tower scanner, BLE Scanner, etc.).

However, the client can additionally or alternatively include any othersuitable components.

The system preferably includes one or more programs 380. The program ispreferably bytecode compilations of user code, wherein the user code isgenerated by a user (e.g., user-generated code). The user's code ispreferably received at the client. The user's code is preferablyabstract, but can be otherwise written. The abstract code is preferablyin any suitable language, including: web-based programming languages(e.g., JavaScript, Node.js, Ruby, PHP, Golang, HTML, java, python,etc.), native programming languages (e.g., C, C++, etc.), and/or anyother suitable programming language.

The abstract code preferably contains one or more variables associatedwith a beacon (e.g., secondary beacon and/or anchor beacon) (e.g.,surfaced by an API). The variables can include scanning control (e.g.,on, off, scanning frequency), advertising control (e.g., on, off,scanning frequency), GPS control, reading from on-board sensors (e.g.,sampling frequency), input reading (e.g., button press responses),output control, and/or any other suitable readout or control parameter.

The abstract code can include beacon population parameters. The beaconpopulation parameters can include human-understandable abstractions(e.g., representation that can be naturally read by humans) such asabstract variables or references associated with one or more beacons(e.g., secondary beacons and/or anchor beacons). The abstract variablesare preferably associated with the disambiguated information (e.g.,beacon identifier or string, geolocation lat/long coordinates, etc.) bya user account associated with the beacon (e.g., beacon owner), but canadditionally or alternatively be automatically associated, learned, orotherwise associated. Examples of abstract variables associated with thebeacons include: a human-readable name for the beacon(s), ahuman-readable identifier for a set of beacons, a human-readableidentifier for a geographic location associated with a set of beacons,and/or any other suitable variable. Specific examples include: a beaconname instead of using the specific beacon identifier such as theidentifier assigned at manufacturing, determined at beacon, etc.; ageographic identifier or venue name instead of listing all beaconsassociated with a given venue, and/or any other suitable populationparameter.

The abstract code is preferably compiled by the remote computing system(e.g., wherein the client sends the abstract code to the cloud, thecloud compiles the code into bytecode, and sends the bytecode to thebeacon), but can additionally or alternatively be compiled at the clientor otherwise compiled.

In one variation, the remote computing system can optionallydisambiguate the abstract variables into machine-level representations,and/or compile the machine-level representations into the bytecode(example shown in FIG. 6). In variants, this hardcodes the beaconinformation (e.g., beacon identifiers, locations, hidden identifierresolution algorithms, etc.) into the bytecode. The remote computingsystem can disambiguate the abstract variables based on a lookup table,using semantic learning, and/or any other suitable disambiguationmethod. In one example, the remote computing system can include a beaconregistry (e.g. lookup table, database, etc.) that associates theabstract variables with beacon information, such as beacon identifiers(e.g., alphanumeric string, manufacturer identifier, public identifier,UUID with major and minor values, etc.) for beacons (e.g., for secondarybeacons, anchor beacons, static beacons, etc.). The beacon registry canoptionally associate the beacon(s) with: beacon groups, geographiclocations (e.g., latitude, longitude, geofence identifier, geographicregion, etc.), and/or any other suitable data. Examples of the abstractvariables include: a user-assigned name for the beacon (e.g.,“conference room), a geolocation identifier (e.g., “home,” “SFOairport,” etc.), a user-assigned name for a beacon group (e.g.,“shipping yards”), or any other suitable abstract variable. In a secondexample, the remote computing system can disambiguate an abstractgeographic reference (e.g., “Denver”) into a set of geolocations or ageographic region (e.g., set of latitude, longitude, and optionallyaltitude values). However, the abstract variables (e.g., human-readabledescriptors) can be otherwise disambiguated into any other suitablemachine-readable representation (e.g., numeric code, references, numericaddresses, etc.)

The abstract code is preferably compiled into bytecode (e.g.,microcode), machine code, or compiled into any other suitable code.

In variants, the bytecode includes disambiguated beacon identifiers(e.g., associated with a specific beacon name, set of beacon identifiersassociated with a predetermined geofence or geographic identifier). Inthese variants, the beacon can automatically respond (according to thebytecode) to receipt of packets from the beacons identified in thebytecode. An example can be seen in FIG. 6.

The abstract code can additionally or alternatively include a cloudprogram. The cloud program preferably functions to respond to eventsreceived from the anchor beacon, but can additionally or alternativelyrespond to events received from any other suitable device (e.g., userdevice). The cloud program is preferably stored in the remote computingsystem, but can additionally or alternatively be stored in the client orotherwise stored. The cloud program can be: generated by the user,standard code, or otherwise determined. The cloud program can be thesame language as that used to generate the beacon program, or any othersuitable language. The cloud program can include serverless architecturefeatures (e.g., lambda™ expressions), dedicated server architecture, orbe otherwise implemented. The cloud program can include one or morebeacon identifiers, one or more events and/or event types, a response(e.g., a response to the event), and/or any other suitable information.For example, a response can include notifying a third party. Notifying athird party can include sending a notification, using communicationcredentials (e.g., an authentication token, an authenticationidentifier, etc.), to a predetermined set of endpoints. In a specificexample, a button press event can be detected by the anchor beacon andreported to the remote computing system. In response to the button pressevent, the remote computing system sends a notification (e.g., message)to a user's device using credentials associated with the Twilio API orany other suitable API.

In an example, while the user is developing instructions in the client,the reomote computing system can process the user code and provide aresource estimation (e.g., power consumption estimate, battery lifetimeprofiler) to the user (e.g., based on the beacon components associatedwith different functions and/or calls, and the estimated powerconsumption for each of the identified beacon components). Additionallyor alternatively, the cloud can determine code refactoring and suggestthe code refactoring to the user through the client.

However, the abstract code can additionally or alternatively include anyother suitable components and/or be otherwise configured.

The system can optionally include one or more remote computing systems400. The remote computing system can function to maintain a globaldatabase (e.g., the beacon repository) of beacon information (e.g., forthe anchor beacon(s), the secondary beacons, etc.). The remote computingsystem can function to process (e.g., compile) code from the client intobytecode and/or transmit bytecode to one or more beacons. Processing thecode received from the client into bytecode can be based on the knownknowledge of the world (e.g., beacon identifiers and locations) and/orany other suitable data.

In one variation, the remote computing system identifies abstractvariables in the abstract code; determines the machine representationfor the abstract variable based on: the abstract variable value, thebeacon population associated with the user providing the code (e.g., theuser's account), and/or any other suitable information; and compiles theabstract code into bytecode using the machine representations for theabstract variables.

The remote computing system can function to generate an event model. Theevent model can be determined from a set of training data (e.g., sampledby the anchor beacon, pre-determined data from a second anchor beacon,pre-determined data from any other suitable beacon, synthetic data,etc.), and a template model (e.g., decision tree, neural network,regression, etc.), or otherwise determined. Training data can be sampledby the beacon while in the training mode, sampled during typicaloperation, or otherwise sampled. The remote computing system canoptionally process the training data to determine positive and negativesamples associated with the event. The template model can be receivedfrom a third party associated with a chipset (e.g., a model specificallyconfigured for the chipset), retrieved from a database, and/or otherwisedetermined. The remote computing system can determine a (trained) modelbased on the training data, and/or any other suitable data (e.g.,pre-determined data such as from other beacons). The event model can becompiled into model bytecode, or otherwise compiled. The model bytecodecan be transmitted to the beacon. The beacon can store the model incomputer readable media. The model can be stored by the main processingsystem, at a sensor-specific processing system, or at any other suitablesystem.

The remote computing system can function to manage beacon defaultsettings (e.g., advertising, transmit power, SSUID on/off, togglefunctionalities, control payload), manage user access to the beacon(e.g., verify that the user pushing code to the beacon is authorizedand/or logged in with the correct credentials), and/or otherwise managethe beacon(s).

The remote computing system can function to store beacon keys (e.g.,complimentary to beacon keys), store authentication tokens (e.g., forthird-party applications), such as communication tokens used to sendnotifications to the user or another endpoint, and/or any other suitableset of keys.

The remote computing system can function to determine a scanningdevice's location based on one or more known locations for theadvertising beacons and a distance indicator (e.g., RSSI) of theadvertisement signal received at the scanning device from theadvertising beacon. For example, the remote computing system cantrilaterate a device's location (e.g., anchor beacon location, userdevice location) based on: the beacon identifiers from packets receivedby the device (e.g., secondary beacon identifiers, anchor beaconidentifiers, etc.), the known locations associated with the beaconidentifiers, and the distance indicators for each packet.

The remote computing system can function to perform actions based on(e.g., responsive to) events detected at the anchor beacon (e.g., send amessage to a user device, management entity, or any other suitablemessage receiver). The actions are preferably performed according to acloud program provided by the user, but can additionally oralternatively be performed in response to satisfaction of a set ofconditions (e.g., beacon event occurrence), or at any other suitabletime.

However, the remote computing system can additionally or alternativelyprovide any other suitable set of functionalities.

The remote computing system can be a remote server system, a mobiledevice, a laptop, a smartphone, a distributed computing system, and/orany other suitable system.

The remote computing system can store a global database of beaconinformation. The beacon information can include: secondary beaconidentifiers, anchor beacon identifiers, the geographic location (e.g.,absolute or relative) associated with the beacon, abstract variablesassociated with the beacon identifiers (e.g., for a given beaconmanagement entity), anchor beacon state (e.g., battery level, etc.),anchor beacon operation parameters (e.g., advertising schedule, etc.),management entity and/or user account associated with the beacon, and/orany other suitable information.

In one variant, the beacon identifiers (e.g., secondary, anchor) can beupdated. For example, the secondary beacon can generate a new secondarybeacon identifier, advertise a packet comprising the new identifier 615.The packet can be received at the anchor beacon and forwarded to theremote computing system. The remote computing system can update theglobal database with the new generated secondary beacon identifier. Anexample can be seen in FIG. 6.

The remote computing system can store an authentication token. Theauthentication token can be used to send messages to third party devices(e.g., the third party device could be associated with the client) inassociation with the user account. In one variation, the authenticationtoken is a Twilio authentication token.

However, the remote computing system can additionally or alternativelybe otherwise configured.

4. Method.

The method preferably functions to track an asset's location and/orstate. The method is preferably performed by the system discussed above,but can additionally or alternatively be performed by any other suitablesystem. The method is preferably performed during an active sessionwherein the active session can be determined by the client, remotecomputing system, or be otherwise determined.

The method preferably includes operating the anchor beacon according toinstructions determined by the client S100. S100 preferably functions toenable the anchor beacon to operate according to client specifiedinstructions (e.g., user code). The instructions can be determined forthe anchor beacon: before the anchor beacon is deployed (e.g.,positioned on an asset), after the beacon is deployed, or at any othersuitable time, and/or periodically updated based on bytecode wherein theperiod is determined by the client.

S100 can include determining the instructions S120. S120 can include:receiving abstract code at the compiling system (e.g., remote computingsystem) from the client, wherein the user enters the instructions intothe client. The compiling system can be: a user device (e.g., laptop,desktop, etc.), browser, remote computing system, and or be any othersuitable system. The instructions can be the program, wherein theprogram includes the abstract code and additionally or alternativelyincludes the cloud program. The abstract code can be compiled and/ordisambiguated, as discussed above, into bytecode. However theinstructions can be otherwise determined.

S100 can include transmitting the bytecode to the anchor beacon S130.The one or more anchor beacons can be identified in the abstract code,be the anchor beacons connected (e.g., wirelessly) to the client, beanchor beacons selected by the user, be anchor beacons associated withthe user (e.g., with the user account), or be any other suitable set ofanchor beacons.

Transmitting can include directly transmitting the bytecode to theanchor beacon(s) (e.g., via a cellular connection, wherein a signal canbe sent to the anchor beacon to turn on the beacon's onboard cellularradio, wherein the bytecode can be transmitted during the next scheduledcellular radio operation period, etc.); indirectly transmitting thebytecode to the anchor beacon(s) (e.g., via web Bluetooth, via thecomputing system running the client, via a computing system wirelesslyconnected to the beacon, or any other suitable connection etc.), and/orotherwise transmitted.

Determining the instructions can include storing the bytecode at the oneor more anchor beacons. The bytecode can be stored in memory, and/or beotherwise stored. However, determining the instructions can additionallyor alternatively include any other suitable elements.

S100 can include executing the bytecode on the anchor beacon. Thebytecode can be processed at the beacon by the anchor beacon's firstprocessor but can additionally or alternatively be processed by anyother suitable processor. In one example, the bytecode can instruct theanchor beacon to use the Bluetooth radio to advertise both iBeacon andEddystone at the same time. In a second example, the bytecode caninstruct the anchor beacon to detect a button press event and inresponse to the event, read the GPS position and send the GPS positionto the remote computing system using the cellular radio.

In one example, the client determines instructions and the remotecomputing system compiles the instructions into microcode (e.g.,bytecode), wherein the instructions specify detecting that the button onthe anchor beacon has been pressed. After the button press event isdetected at the anchor beacon, the information is enqueued in thepayload to be broadcast by the anchor beacon. The payload is transmittedto the remote computing system, the cloud program processes the payloadto determine the button has been pressed, and in response to the buttonpress event, the cloud program takes an action (e.g., send a message tothe client, and/or any other suitable device, using the authenticationtoken).

However, S100 can additionally or alternatively include any othersuitable elements.

The method can additionally or alternatively include operating theanchor beacon according to a learned model at S200. S200 preferablyfunctions to at the anchor beacon: gather training data, and duringoperation, recognize an event associated with the training data. S200 ispreferably performed by the second processor, but can additionally oralternatively be performed by any other suitable processor. S200 ispreferably performed in parallel with S100, but can additionally oralternatively be performed at any other suitable time (e.g., beforeand/or after).

S200 preferably includes the training mode 505 and the processing mode530 as shown in FIG. 2. The beacon or event model can be trained asdiscussed above, or be otherwise trained. S200 can additionally oralternatively include any other suitable modes.

In one example of S200, while the anchor beacon is in training mode todetect a drop event, the user can drop the beacon 10 times. The anchorbeacon can record the data and stream the data to the cloud. At theremote computing system, the data can be processed and an event modelcan be determined. The event model can be transmitted to the anchorbeacon. At the anchor beacon, after receiving the event model, theanchor beacon detects a drop event and transmits the event label to theremote computing system.

Embodiments of the system and/or method can include every combinationand permutation of the various system components and the various methodprocesses, wherein one or more instances of the method and/or processesdescribed herein can be performed asynchronously (e.g., sequentially),concurrently (e.g., in parallel), or in any other suitable order byand/or using one or more instances of the systems, elements, and/orentities described herein.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A system, comprising a remote computing system and ananchor beacon, the anchor beacon comprising: a first processor operablyconnected to an inertial measurement unit, wherein the first processoris operable between a training mode and a processing mode, wherein thefirst processor is configured to log data associated with an event inthe training mode, and is configured to detect the event in theprocessing mode; a Bluetooth system, wherein the Bluetooth system isoperable between a plurality of modes comprising a scanning mode and anoffline mode, and wherein the Bluetooth system is configured to scan fora venue beacon packet associated with a venue beacon in the scanningmode; and a second processor, separate and distinct from the firstprocessor, that is configured to process the venue beacon packet andgenerate a payload according to custom instructions; a cellular system,wherein the cellular system is configured to: transmit the payload to aremote computing system; and receive a remote payload from the remotecomputing system; a security system, wherein the security systemcomprises a random number generator.